Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props rishabhwp, sirlouen.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@R1shabh-Gupta thanks for the patch
I will start reviewing it. I just one to comment one thing that would be great for the future
When you send a PR, also send a message in Trac informing about the patch. Problem with PRs is that it doesn't send notifications. Every time you sent a patch for any ticket I have in my follow list, I don't see it until I happen to be reviewing the old tickets by chance (and maybe there are more I have not already seen)).
Just write something: "Patch sent to GH"
Also, its easier to miss props with GH patches than Trac messages (specially when there are many PRs in a single ticket)

I’ve added a test for this and noticed a few points worth highlighting:

1. PHPMailer encoding downgrade
   As mentioned by @SirLouen, the original test assertion:

   $this->assertEquals( '8bit', $mailer->Encoding );

   fails because PHPMailer automatically downgrades the encoding from 8bit to 7bit when the message body contains no 8-bit characters (see PHPMailer.php, line 2875). In our case, we were sending 'Short email' as the body, which is pure ASCII, so the encoding was downgraded to 7bit, leading to the test failure.
   To address this, I’ve added an 8-bit character to the message body — 'Short email –' — ensuring PHPMailer keeps the encoding as 8bit and allowing the test to pass.

2. MockPHPMailer behavior difference
   In mock-mailer.php, the preSend() method explicitly sets:

   $this->Encoding = '8bit';

   This step does not occur in the real PHPMailer implementation. As a result, the mock partially hides the encoding downgrade behavior, though the issue still appears in the actual email headers.

Let me know if anything else should be addressed.